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Status of this Memo 
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does not specify an Internet standard of any kind. Distribution of 
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Abstract 
As required by Routing Protocol Criteria [1], this report documents 
the key features of Triggered Extensions to RIP to Support Demand 


Circuits [2] and the current implementation experience. 


As a result of the improved characteristics of Triggered RIP, it is 
proposed that Demand RIP [5] be obsoleted. 
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1. Protocol Documents 


"Triggered Extensions to RIP to Support Demand Circuits" [2] suggests 
an enhancement to the "Routing Internet Protocol" (RIP) [3] and 
"RIP-2" [4] to allow them to run more cost-effectively on Wide Area 


Networks (WANs). 
2. Applicability 


Triggered RIP requires that there is an underlying mechanism for 
determining unreachability in a finite predictable period. 


The triggered extensions to RIP are particularly appropriate for WANs 


where the cost - either financial or packet overhead - would make 
periodic transmission of routing (or service advertising) updates 
unacceptable: 

o Connection oriented Public Data Networks - for example X.25 packet 


switched networks or ISDN. 
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o Point-to-point links supporting PPP link quality monitoring or 
echo request to determine link failure. 


A triggered RIP implementation runs standard RIP on Local Area 
Networks (LANs) allowing them to interoperate transparently with 
implementations adhering to the original specifications. 


3. Key Features 


The proposal shares the same basic algorithms as RIP or RIP-2 when 
running on LANs; Packet formats, broadcast frequency, triggered 
update operation and database timeouts are all unmodified. 


The new features operate on WANs which use switched circuits on 
demand to achieve intermittent connectivity; Or on permanent WAN 
connections where there is a desire to keep routing packet overhead 
to a minimum. Instead of using periodic '’broadcasts’, information is 
only sent as triggered updates. The proposal makes use of features 
of the underlying connection oriented service to provide feedback on 
connectivity. 


3.1 Triggered Updates 


Updates are only sent on the WAN when an event changes the routing 
database. Each update is retransmitted until acknowledged. 
Information received in an update is not timed out. 


The packet format of a RIP response is modified (with a different 
unique command field) to include sequence number information. An 
acknowledgement packet is also defined. 


3.2 Circuit Manager 


The circuit manager running below the IP network layer is responsible 
for establishing a circuit to the next hop router whenever there is 
data (or a routing update) to transfer. After a period of inactivity 
the circuit will be closed by the circuit manager. 


If the circuit manager fails to make a connection a circuit down 
indication is sent to the routing application. The circuit manager 
will then attempt at (increasing) intervals to establish a 
connection. When successful a circuit up indication is sent to the 
routing application. 
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3.3 Technology Restrictions 


There is a small but nontrivial possiblility of an incorrectly 
configured or poorly operating link causing severe data loss, 
resulting in a ’black hole’ in routing. This is often unidirectional 
- the link that route updates cross works properly, but not the 
return path. 


Triggered RIP will NOT fuction properly (and should NOT be used) if a 
routing information will be retained/advertised for an arbitrarily 
long period of time (until an update in the opposite direction fails 
to obtain a response). 


To detect black holes in technologies which use PPP encapsulation, 
either Echo Request/Response or Link Quality Monitoring should be 
used. When a black hole is detected a circuit down indication must 
be sent to the routing application. 


Current (and future) technologies which do not use PPP, need to use 
an equivalent ’are-you-there’ mechanism - or should NOT be used with 
Triggered RIP. 


3.4 Presumption of Reachability 
In a stable network there is no requirement to propagate routing 
information on a circuit, so if no routing information is (being) 
received on a circuit it is assumed that: 


o The most recently received information is accurate. 


o The intervening path is operational (although there may be no 
current connection). 


If the circuit manager determines that the intervening path is NOT 
operational routing information previously received on that circuit 
is timed out. It is worth stressing that it can be ANY routed 
datagram which triggers the event. 


When the circuit manager re-establishes a connection, the application 
exchanges full routing information with its peer. 


3.5 Routing Information Flow Control 
If the circuit manager reports a circuit as down, the routing 


application is flow controlled from sending further information on 
the circuit. 
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4. 


Relationship to Demand RIP 


The Triggered RIP proposal [2] has a number of efficiency advantages 
over the Demand RIP proposal [5]: 


o When routing information changes Demand RIP sends the full 
database to its partner. 


Once a router has exchanged all routing information with its 
partner, Triggered RIP sends only the changed information to the 
partner. This can dramatically decrease the quantity of 
information requiring propagation when a route change occurs. 


o Demand RIP requires a full routing update to be stored by the 
receiver, before applying changes to the routing database. 


A Triggered RIP receiver is able to apply all changes immediately 
upon receiving each packet from its partner. Systems therefore 
need to use less memory than Demand RIP. 


o Demand RIP has an upper limit of 255 fragments in an update. This 
sets an upper limit on the sizes of routing and service 
advertising databases which can be propagated. 


This restriction is lifted in Triggered RIP (which does not use 
fragmentation). 


In all other respects Demand RIP and Triggered RIP perform the same 
function. 


Obsoleting Demand RIP 

While it is possible that systems could be able to support Demand RIP 
and Triggered RIP, the internal maintenance of structures is likely 
to differ significantly. The method of propagating the information 
also differs significantly. In practice it is unlikely that systems 


would support Demand RIP and Triggered RIP. 


As a result of the improved characteristics of Triggered RIP, it is 
proposed that Demand RIP [5] be obsoleted. 


Implementations 


At this stage there are believed to be two completed implementation. 
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The Xyplex implementation supports all the features outlined for IP 
RIP-1, IP RIP-2, IPX RIP, and IPX SAP. However, it only supports one 
outstanding acknowledgement per partner. The implementation has been 
tested against itself on X.25, ISDN, Frame Relay, V42bis CSU/DSUs, 
and asynchronous modems. It has also been tested in operation with 
various router and host implementations on Ethernet LANs. 


The DEC implementation supports IP RIP-1 over ISDN, Frame Relay, 
leased lines and V.25bis. The Xyplex and DEC IP RIP-1 
implementations have been checked for interoperability over ISDN 
without problems. 


7. Restrictions 
Demand RIP relies on the ability to place a call in either direction. 
Some dialup services - for example DTR dialing - allow calls to be 
made in one direction only. 
Demand RIP can not operate with third-party advertisement of routes 
on the WAN. The next hop IP address in RIP-2 should always be 
0.0.0.0 for any routes advertised on the WAN. 


8. Security Considerations 


Security is provided through authentication of the logical and 


physical address of the sender of the routing update. Incoming call 
requests are matched by the circuit manager against a list of 
physical addresses (used to make outgoing calls). The routing 


application makes a further check against the logical address of an 
incoming update. 


Additional security can be provided by RIP-2 authentication [2] where 
appropriate. 


Sherry & Meyer Informational [Page 5] 


RFC 2092 Triggered RIP Protocol Analysis January 1997 


References 


[1] 


[2] 


[3] 


[4] 


[5] 


Hinden, R., “Internet Engineering Task Force Internet Routing 
Protocol Standardization Criteria", RFC 1264, Bolt Beranek and 
Newman, Inc, October 1991. 


Meyer. G.M. and Sherry, S., "Triggered Extensions to RIP to 
Support Demand Circuits", RFC 2091, Shiva and Xyplex, Aug 1995. 


Hedrick. C., "Routing Information Protocol", RFC 1058, Rutgers 
University, June 1988. 


Malkin. G., "RIP Version 2 - Carrying Additional Information", 
RFC 1723, Xylogics, November 1994. 


Meyer. G., "Extensions to RIP to Support Demand Circuits", 
Spider Systems, February 1994. 


Authors’ Address: 


Sherry & Meyer Informational [Page 6] 


Steve Sherry 

Xyplex 

295 Foster St. 
Littleton, MA 01460 


Phone: (US) 508 952 4745 
Fax: (US) 508 952 4887 
Email: shs@xyplex.com 


Gerry Meyer 

Shiva Europe Ltd 
Stanwell Street 
Edinburgh EH6 5NG 
Scotland, UK 


Phone: (UK) 131 561 4223 
Fax: (UK) 131 561 4083 
Email: gerry@europe.shiva.com 


